中国民生银行灾备自动化切换调度平台实践与应用
【摘要】中国民生银行在灾备建设的过程中，自行研发了一套灾备自动化调度指挥平台，用于日常灾备系统管理、切换演练、灾备切换、状态监控展现和应急启停。平台投入使用第一年就陆续接入几十套同城和异地灾备业务系统，得益于弹性灵活的流程编排特性，灾备系统接入时间大大缩短，后期变更维护的工作量大幅度减少；切合实际需求的桌面演练、应急启停、跳过和重做失败步骤等功能的实现，提高了系统可用性和用户满意度。灾备自动化调度指挥平台随着需求的更新、应用新架构的引进而不断演进，以支持我行所有场景下的自动化灾备切换操作。【作者】中国民生银行信息科技部 张永军 白东旭张永军，大连理工大学硕士研究生毕业，辗转于中科院计算所、HP，现任职于中国民生银行。多年工作在一线，运维老兵一枚，深谙运维压力与痛苦，致力于运维标准化、自动化、智能化。白东旭，2012年加入中国民生银行信息科技部系统管理中心，负责x86服务器硬件选型与运维和操作系统运维。精通Linux,Windows,Aix操作系统管理，熟悉虚拟化，容器技术，掌握Python,Go等语言和Ansible等自动化运维工具，2015年以来参与民生银行灾备平台建设与运维。
1、中国民生银行灾备建设背景介绍
近年来随着银监会《商业银行数据中心监管指引》和《商业银行业务连续性监管指引》等规范的陆续出台，监管部门对商业银行信息系统业务连续性管理提出了很高的要求，特别是要求定期开展灾备切换演练，而随着业务系统架构多样性及复杂性的不断提高，整个切换流程将变得越来越复杂，同时演练中对于流程控制的要求也变得越来越高。
民生银行在灾备建设中采用的是大同城小异地的两地三中心灾备方案，同城两个机房采用了网络大二层打通的技术，主要目的是实现同城应用双活和系统在任意机房运行，在灾备技术方面，由于行内新核心刚刚上线不久，因此没有采用对应用有改造需求的应用端双活技术，而数据库日志传输技术可能会导致数据丢失，灾难时无法保证RPO=0，因此我们在现有技术栈基础上，采用了改造和影响最少的存储复制技术，虽然在切换过程中需要激活灾备端的各种资源，会导致RTO时间较长，但是可以尽力保证RPO=0。
存储复制技术带来的灾备切换问题主要有：流程复杂，切换步骤多，逐层操作的IT模块多，切换时间长。因为银行业务特点和技术栈的原因，我行业务系统数量非常多，而且使用了各种IT技术，存储方面有EMC SRDF/SWAP/STAR以及华为HyperReplication，数据库方面有DB2、ORACLE、MySQL、DB2 HADR、ORACLE RAC、MySQL MHA以及DB2 PureSacle GDPC、Oracle extend RAC等，操作系统方面包括Suse Linux、IBM AIX、HP Unix、Oracle Solaris以及相应的集群技术，中间件包括Weblogic、Tomcat、Apache、Nginx、ActiveMQ、IBM MQ等。日常灾备切换演练和真实灾备切换时间压力比较大。
灾备切换面临的主要问题除保证RPO的前提下尽量减小RTO外，还包括跨部门指挥协调问题、切换流程进度监控问题、以及众多流程的维护问题。灾备切换时要考虑如何解决这些问题，实现安全有序的灾备切换，这样就需要一款能自动化执行、对所有系统的切换流程可以指挥调度的平台。
我们从2015年开始进行灾备指挥平台的建设，项目初期我们曾尝试通过某IT公司咨询来解决我们的问题，但是后来发现洋洋洒洒几百页无法落地的ppt并不能解决上述问题，为此我们也曾了解过业内几个灾备切换产品，这些产品大多需要深度定制，而且大多无法实现自动化操作，或者在流程编排方面只能采用一个系统一个场景对应一个流程的方式编排，缺乏灵活性，当系统和场景复杂时对流程的维护是一个大问题。
基于以上背景，我们决定自行架构开发一套符合我行使用需求的灾备自动化调度指挥平台。
2、灾备自动化调度指挥平台需求分析
银行的数据中心一般采用两地三中心架构，分为同城生产和灾备中心，异地灾备中心，可能采用大同城架构，也可能大异地架构，甚至采用异地双活。目前因技术和财务限制，大多数银行业务没有采用双活架构，而是按照业务系统重要性在同城或者异地搭建容灾环境。常见的可能面对的灾难场景有整个站点故障、网络问题导致整个网络区域服务不可用、主机或者存储故障导致部分服务不可用，等等。那么平台不仅要支持单一系统的切换，还要支持多系统的站点的切换，针对网络区域故障、存储故障的切换。
考虑到场景复杂，灾备系统数量多，在确保RTO基础上，既要做到灾备切换过程可控，满足多种容灾场景，还要提高跨部门沟通效率，我们对平台需求做了如下分析：
1）架构分层，逐层解耦
为加快灾备建设进度，保护行内已有投入，灾备指挥平台需要采用松耦合分层架构，实现通用性和弹性，层与层之间没有强依赖，使用API接口调用，每一层都可以使用市面上符合要求的开源或商用产品。主要分层包括：展示层、数据层、调度指挥引擎、流程引擎、消息中间件层、自动化层。
2）将流程步骤与具体系统分开定义
业界部分产品平台采用一套系统一个场景对应一个流程的设计，最大的问题是无法灵活应对各类场景，无法充分复用标准化流程。我们希望架构一个平台，使用一套带有分支的标准通用流程，满足所有系统的各种切换场景。
3）依据切换的系统和选择的场景实时生成灾备切换流程
在模块化组件基础上建立一套通用流程，以及由此组合派生的与多种场景对应的切换流程，如何进一步实现具体应用系统的灾备切换呢？为更加弹性和通用性，就需要将流程本身与业务系统具体配置进行解耦。配置解耦就是将流程、系统、脚本解耦，将流程参数化，分别维护。在充分解耦的基础上，对通用流程进行定制，系统信息作为参数，把通用流程实例化成各个应用的各种场景流程。
为实现一个通用弹性满足我行灾备自动化切换要求的平台，我们建立了一个数据模型，用户前台确定需要切换的系统，选择相应的切换场景或方式，经数据处理引擎处理后，能自动生成针对该场景的流程步骤。弹性通用流程体系使用三层体系架构实现：模型化的通用组件、能反映灾备切换周期特点的灾备步骤、根据灾备特点由一个或多个灾备步骤组合而成的流程。通过系统名称再去关联系统配置信息，生成相关具体步骤和启停脚本使用的参数。生成应用系统对应的流程就是将该场景关联的通用流程实例化的过程，通用流程作为一个超集，应用只需实现自身需要的步骤，将应用配置信息作为参数传递给流程和脚本。数据处理引擎就是数据驱动的，能动态的将用户选择转换成可以用于调度指挥、自动化执行的流程的实现逻辑，如此平台就不必维护数百个流程。
3、灾备自动化调度指挥平台技术架构设计
我们同城中心网络是大二层，存储采用商用存储的复制技术，主机主要有小型机和x86服务器，灾备使用的技术种类繁多，如何在平台使用最少的组件、最少的流程来实现更多的可能，这是平台优先考虑的问题。
1）操作原子化
在现实生活中，乐高积木自由拼接、分层次搭建无疑是最典型的一种实现。一套通用积木块可以搭建成多种机器人，控制程序用于驱动机器人的可控积木块，让机器人动起来。各种机器人就相当于各种场景下的标准流程，控制程序相当于自动化实现的各个应用系统具体场景下的切换流程。对应于灾备自动化调度指挥平台，先构建模块化组件，搭建成通用的流程，再组合成各种场景流程，将组件绑定脚本实现自动化，再为每个应用系统实现定制化的流程。
我们将使用的IT产品标准化，匹配启停、检查等动作类型进一步模块化、原子化，再搭配通用脚本实现自动化。模块化组件是弹性流程的基础，简化了复杂的异构问题。针对我行使用的40多种IT产品，我们构造了60个自动化实现的模块化组件，编写了60个通用脚本，实现了所有产品的启停和状态检查。以此为基础，组合成一个具有500多个原子步骤的具有多个分支的通用切换流程。为多套应用系统实现了4700多个流程步骤，组成应对各种场景的600余套流程。
2）原子步骤的标准化操作分组
两个2*4大小的同色积木模块，它们有多少种搭建可能呢？——17种！
与之类似，两个IT组件，集群和应用，都具有相应的启停操作，可以构成4个原子化操作，再按照灾备周期划分，可以包含启/停主生产集群/应用、启/停灾备端集群/应用共8个原子步骤，这些步骤属于一个简化的标准灾备切换流程的4个灾备周期步骤：停止生产-启动灾备-停止灾备-启动生产。不同的场景需要的周期步骤不同，只要提前定义每个场景对应的步骤列表，就可以依据场景的选择和设定生成针对该场景的具体的流程。
灾备周期步骤的自由组合搭配就如同积木搭建一样丰富多彩，一套通用流程就可以成就无限可能。示例中组合构建了5个流程对应相应的场景，实际上，我们就是这样实现的应对各种灾难场景的切换流程。
3）通用切换流程的实例化
现在有了在模块化组件基础上建立的一套通用流程，以及由此组合派生的与多种场景对应的切换流程。标准模板流程有了，怎么实现具体应用系统的灾备切换呢？
根据需求分析的考虑，我们使用配置解耦，将流程、系统、脚本解耦，将流程参数化，系统信息作为参数，这样就可以把通用流程实例化成各个应用的各种场景流程。生成具体系统的切换流程就是通用流程的实例化。
在实现过程中我们梳理通用切换流程，梳理成通用流程表；将灾备相关配置数据分别写入主机表、应用表、集群表、网络表、存储表等。这样当业务系统接入灾备环境，只需要填写配置信息表就可以由灾备自动化调度指挥平台生成切换步骤并下发到自动化模块执行。
4）灵活切换
在切换技术上，灾备自动化调度指挥平台有四项功能值得特别提一下：动态展示、分层切换、串并行执行、桌面演练。
（1）动态展示
在流程设计时，我们将灾备切换流程的展示分为4个层次：大的流程阶段、阶段内步骤组合、原子步骤、实例化的具体原子操作，基于动态页面技术，自动生成各系统的流程展示。
（2）分层切换
每套灾备系统包含的主机和应用可能很多，因此我们将应用系统进行分层，分为DB、APP、WEB、辅助、前置等。我行使用的同城大二层网络打通的技术，可以使每层独立切换，整个系统多个分层可以运行在不同机房，或者构建应用系统特定分层的双活。除了分层之外，网络上对不同功能进行了分区，如业务后台区、互联网区、外联区等。一套系统的一个应用分层属于一个网络分区，而一个网络分区可能包含多个应用分层。灾备自动化调度指挥平台实现了应用的灵活分层切换，以及在分层基础上的网络分区切换和存储故障切换。系统在切换时可以选择只切换受影响的分层，也可以切换整个系统所有分层（即所有主机上的应用）。
（3）串并行执行
灾备切换自动化要优先考虑RTO，要确保流程高效运转和自动化执行的可靠性，传统上的单纯串行严重影响效率，单纯并行则会导致有顺序依赖的应用启停失败，为此我们使用了分层次串并行组合的自动化运行机制。
第一层，多个系统切换流程可以并行执行；
第二层，一个系统流程内的大步骤串行执行；
第三层，在大操作步骤内，根据启停依赖性要求，在尽可能提升执行效率的情况下使用了串行和并行混合操作。
（4）桌面演练
正式切换时一个系统的灾备流程能否正常流转、能否按照预期自动执行，相信没人可以打包票，那么就需要提供一种机制在切换前确保流程将会按照我们设计时的预期逐步执行。我们使用桌面演练功能解决这个问题。每个脚本都需要支持check选项，并在脚本中提供其实现，以支持和区分是真实切换还是桌面演练。通过在前台选择参与切换的系统、切换类型、特定场景以及是真实切换还是桌面演练来产生具体流程步骤，关联应用系统配置信息，生成命令和参数，登陆到主机和网络设备验证连通性，之后利用脚本中的check=true的分支将真实切换时待执行的具体命令及参数以 --debug: {待执行命令及参数}的形式打印出来，在此过程中与真实切换操作唯一的不同就是只是生成命令而不执行。
4、灾备自动化调度指挥平台使用情况
灾备自动化调度指挥平台上线后解决了：
（1）流程定制维护问题，使用统一的通用流程，无需系统负责人自己定义和维护流程，简化了难度，降低了工作量；
（2）灾备切换自动签到和公告发布功能，可以清晰了解到灾备切换人员参与情况和重大通知进度情况；
（3）问题工单，当自动化步骤失败时根据每个步骤的负责人设置派发工单，流程暂停，问题解决后流程继续自动化流转；
（4）进度监控和回看，支持ECC大屏和桌面台式机监控界面，支持进行中和已完成的流程回看已完成步骤的详细情况；
（5）切换历史和报告，方便地统计每个周期内的系统切换情况，并按照监管和运维要求导出html或word格式切换报告和应急手册。
平台在异常应对方面做了充分考量：从决策支持、场景选择、健康和性能检查、桌面演练、全自动操作、高并发执行都做了有益探索，尤其是应对异常方面，支持自动步骤失败后派发人工处理和重试、替换预定的步骤、跳过特定步骤、整个流程转换为人工执行、流程紧急终止以及全调用路径日志等功能。如果灾备自动化调度指挥平台本身出现故障，可以切换到两地三中心其他备用平台进行操作，支持流程断点继续。所有站点的灾备平台或者自动化基础设施都有问题时，还可以使用灾备自动化指挥调度平台生成的离线灾备切换预案进行人工切换。
另外，业内的大多数类似产品只用于灾备切换，我们对灾备自动化调度指挥平台进行了扩展，可以作为监控和应急启停使用：支持实时查看两地三中心灾备系统运行状况，也可以对故障的应用独立地启停。启停过程中可以实时监控执行日志，直到执行成功。
在推广应用过程中，灾备自动化调度指挥平台实现了RTO保证，从原来人工操作的数小时多人参与降为无人值守数分钟就可以完成灾备切换：
（1） 全自动操作减少了对人的依赖，有效规避操作风险；
（2）平台覆盖了十余个行内定义的切换演练和灾难场景；
（3）一键切换，紧急情况下一人即可完成系统灾备切换；
（4）组件化模块、充分解耦，大大加快了应用验证测试和投产实施进度，更加安全、可靠、高效，一年内实现了数十套系统的切换测试和上线，包含数百台主机、上千个应用，每年支持百余次/套灾备切换演练和千余次桌面演练。
总体上来说，灾备自动化调度指挥平台实现了灾备系统切换流程的灵活编排，提高了业务系统接入的效率，实现了RTO目标，提高了参与切换人员整体满意度。
5、创新点
综上所述，在灾备自动化调度指挥平台方面我们主要做了如下尝试：
1）积木式拼接，分层次搭建
2）设计了一套数据处理引擎，使用数据驱动流程
3）在此基础上，我们在流程构建、切换技术、运维支持上按照我们的实际需求进行了一些创新：
首先，在流程构建上的创新，包括：
（1） 组件模块化用来解决异构问题；
（2） 通用流程以应对各种切换场景和切换方式；
（3） 充分解耦，按需定制可以灵活地定义应用系统灾备切换流程；
（4） 依据应用配置信息自动化建立应用系统的逻辑模型，并模拟切换。
其次，在切换技术上的创新，包括：
（1） 大二层打通基础上灵活的应用系统分层跨机房切换；
（2） 兼顾效率和可靠性的串并行执行。
另外，在运维支持上的创新，包括：
（1） 平台可以应对各种异常状况，保证实战性；
（2） 可以对两地三中心灾备系统进行监控以及对单个应用进行应急启停；
（3） 有效应对流程、应用变更，确保两地三中心一致性。
6、后记
以上是我们在建设和使用灾备自动化调度指挥平台的需求分析、技术架构、使用过程和遇到问题，由于各个公司灾备架构不同，使用的技术栈各异，汝之蜜糖，彼之砒霜，再加上该平台在2015年8月份即投入使用，如今技术和背景已经大不同，肯定不可能拿来即用，只是希望我们的技术思路、经验教训能给大家提供些微帮助，在建设过程中少走些弯路，期待市场上出现更加成熟稳定、通用可靠的灾备自动化调度指挥类产品。
如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
存储容灾规划和自动化切换最佳实践
http://www.talkwithtrend.com/Article/160733
欢迎关注社区 “灾备”技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/3457
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场